DatetimeParts and the native Date API don't use the same conventions, and two fields are mismatched here:

1. month is off by one. Date.getMonth() is 0-indexed (January is 0), but DatetimeParts.month is 1-indexed (January is 1). So today, June, comes through as month 5, which DatetimeParts reads as May.

2. day is the wrong field entirely. Date.getDay() returns the day of the week (0–6, Sun–Sat), not the day of the month. The day of the month comes from Date.getDate().

You can reproduce it with a plain no-value date picker (no constraints needed): the calendar lands on Jun 17, 2026 but the button reads "May 3, 2026".

Both of these can be seen with:

<ion-item>
  <ion-label>Start Date</ion-label>
  <ion-datetime-button slot="end" datetime="no-value-date"></ion-datetime-button>
</ion-item>

<!-- keep-contents-mounted makes the datetime (and the button text) compute on load, so the mismatch shows immediately -->
<ion-modal keep-contents-mounted="true">
  <ion-datetime locale="en-US" presentation="date" id="no-value-date"></ion-datetime>
</ion-modal>

Fix:

getClosestDate is awaited on every call, but the result is thrown away whenever parsedValues is non-empty (i.e. whenever the datetime has a value). Since getClosestDate is a Stencil @Method, this is an async cross-component round-trip on every ionValueChange, just to discard the result. Move it into the no-value branch and also update the comment:

I'd recommend an @internal method instead of a new public one.

componentWillLoad already computes this.defaultParts (today snapped to the closest valid value via getClosestValidDate, datetime.tsx:1540) — exactly what the button is trying to reconstruct. So the button can just read that value rather than recomputing it from a Date, which also guarantees the button and picker never disagree.

Making it @internal follows how these two already communicate (the button listens to the @internal ionValueChange event), and avoids adding public API to document and support. It also avoids reconstructing parts from a Date (the ISO -> removeDateTzOffset round-trip), which is where the getMonth()/getDay() mistakes lived.

The datetime-button.tsx then reads it in the no-value branch

/**
     * Both ion-datetime and ion-datetime-button default to today's date and
     * time if no value is set. We read the datetime's computed default so the
     * button respects the same constraints (min, max, minuteValues, etc.) that
     * the datetime applies to its own fallback, instead of using a raw "now".
     */
    const parsedDatetimes =
      parsedValues.length > 0 ? parseDate(parsedValues) : [await datetimeEl.getDefaultPart()];

This helper can go away. It only exists because the earlier getClosestDate(date) method needed reusable logic, but now that getDefaultPart() just returns the already-computed this.defaultParts, this has a single caller (componentWillLoad). I'd revert it back to how it was originally.

getDefaultPart() already returns DatetimeParts, so wrapping it in convertDataToISO(...) only to feed it back through parseDate is a parts → ISO → parts round-trip. You can read it directly and skip both the conversion and the convertDataToISO import:

Unless there's a reason of why you went with this approach?

Why is this change necessary?

Why is this change necessary?

Why is this change necessary?

As mentioned in https://github.com/ionic-team/ionic-framework/pull/31218/changes#r3463042864, I would revert this.

Please remove the await page.pause() calls from these tests. page.pause() is a debugging only tool that halts the run and opens the Playwright Inspector, so it shouldn't ship in the suite.

These constraint tests should be annotated with the issue they're covering, like the existing #27797 tests in this file do.

expectedTime = fixedTime copies the reference, so setMinutes/setHours/setMonth mutate fixedTime itself. It's harmless here only because fixedTime isn't read again.

Optional / nice-to-have, take it or leave it. These four tests repeat the same clock setup and formatter definitions. We already share per-describe setup with beforeEach elsewhere in this file (see datetime-button.e2e.ts:27 in the "switching to correct view" describe), so we could do the same here. Hoist the constant time and the formatters to the describe scope and set the clock in a beforeEach, then each test only carries its own setContent and expected value:

  test.describe(title('datetime-button: datetime constraints'), () => {
    const fixedTime = new Date('2026-06-18T17:54:54.518Z');

    const dateFormat = new Intl.DateTimeFormat('en-US', {
      weekday: 'short',
      month: 'long',
      day: '2-digit',
    });
    const timeFormat = new Intl.DateTimeFormat('en-US', {
      hour: '2-digit',
      minute: '2-digit',
    });

    test.beforeEach(async ({ page }) => {
      await page.clock.setFixedTime(fixedTime);
    });

Then each test drops its local fixedTime, setFixedTime, and Intl.DateTimeFormat lines and just uses the shared ones. For the expected value, clone before mutating so the shared fixedTime isn't altered between tests:

const expectedTime = new Date(fixedTime);
expectedTime.setMinutes(0);.

One caveat if you do take this: once fixedTime is shared across tests, cloning it before mutating becomes necessary (not just tidy), otherwise a mutation in one test leaks into the others via beforeEach.